...and have the unit tests run directly on Firefox (or try)

[This is draft, full description will come later]

[UPDATE]

From the commit message:

In order to access the web extensions APIs directly on
the browser we need to play a bit of a telephone game.

We use selenium to instantiate and run code as if on the
browser console, but on the console we still don't have access
to the webextensions APIs neither can we send messages directly
the a web extensions background script.

It occured to me that I may be wrong about not being able to directly message the background script, but such a change, if confirmed, could be done in a follow up. It would remove a bit of the complexity, by making the content script unnecessary.

With this in mind, we send a custom event ("test") from the console,
which will contain information about the exact web extention API we
want to access and with what arguments we want to execute it.

Packed with this commit is a webextension that I created to help with
these tests. The content script of this web extension listens for the
"test" custom events. Whenever a new one is received, the content
script, which still doesn't have access to most web ext APIs, will pass
the message from the website to the background script.

The background script of this webextension, is listening for such
messages, and will process the message and execute the requested API.
When that is done, the background script will pass the response back to
the content script. The content script will send the response back in
another custom event ("testResponse").

The tests will listen for "testResponse" events, when this event is
received we step out of the executeAsyncScript block and return the
response received.

All of this will happen inside a proxy around the desired web ext APIs,
so that calling code doesn't even need to know all that is happening and
can hapilly call web ext APIs without worrying.